假設 User 按下：

Place Order

Backend 可能需要：

Create Order
Update Inventory
Process Payment
Send Email
Send Notification
Generate Invoice
Record Analytics

如果所有工作都必須依序完成，User 就必須一直等待；如果 Email Service
暫時掛掉，也不代表 Order 一定應該失敗。

今天介紹：

Message Queue

但先從幾個必要的新名詞開始。

---

Synchronous 是什麼？

先用一句話理解

你可以先把 Synchronous 記成：

「我叫你做一件事，我先在這裡等你做完，拿到結果後我才繼續。」

例如你打電話問餐廳：

你：請問今天晚上 7 點還有位子嗎？
        ↓
你不會先掛電話
        ↓
等待店員查詢
        ↓
店員：有位子
        ↓
你才繼續訂位

因為下一步需要前一步的結果，所以必須等。

**Synchronous（同步）**可以先理解成：

呼叫一個工作後，需要等待它完成，才能繼續。

Backend
 ↓
Payment Service
 ↓
等待 Result
 ↓
Success
 ↓
繼續

像在櫃台點餐後站著等餐完成。

Synchronous 並不是不好。Login、Payment Authorization
等需要立即知道結果的工作，本來就很適合 Sync。

---

Asynchronous 是什麼？

先用一句話理解

你可以把 Asynchronous 記成：

「我先把工作交給你，不需要站在這裡等你做完，我可以先去做其他事情。」

例如餐廳給你一個取餐震動器：

點餐
 ↓
拿到震動器
 ↓
先去座位坐
 ↓
廚房繼續做餐
 ↓
完成後再通知你

重點不是「工作不用做」，而是：

工作仍然會做
只是呼叫它的人不必一直等待

**Asynchronous（非同步）**可以理解成：

送出工作後，不一定要等它完成，就可以繼續其他事情。

例如 Order 已建立：

Create Order
 ↓
安排 Send Email
 ↓
Response User

Email 可以稍後處理。

像餐廳：

點餐 → 拿號碼牌 → 去坐下 → 完成後通知

---

Critical Path 是什麼？

更直覺的理解

Critical Path 可以先想成：

「如果這一步沒完成，User 的主要事情就不能算成功。」

例如買東西時：

Payment Failed
→ 不能告訴 User「付款成功」

但：

Welcome Email 暫時沒寄出去
→ 不一定要讓整筆訂單失敗

所以判斷一個工作是不是 Critical Path，可以問：

「這件事如果現在沒完成，User 的核心操作還能不能算成功？」

Critical Path 是 User 完成核心操作時，必須成功經過的步驟。

Checkout 可能是：

Validate Cart
 ↓
Check Inventory
 ↓
Payment
 ↓
Create Order

而：

Email
Analytics
Push Notification

通常不一定需要阻塞核心 Request。

因此常見思路：

Critical Work → Sync
Background Work → Async

實際仍要依 Requirement 決定。

---

Queue 是什麼？

最簡單的生活例子

Queue 就像：

排隊買咖啡

很多人同時來時，不需要 10 個人一起衝到櫃台：

Customer A
Customer B
Customer C
    ↓
排隊
    ↓
一個一個被處理

在 System 裡也是一樣：

很多工作突然進來
      ↓
    Queue
      ↓
慢慢交給 Worker 處理

Queue
的價值之一，就是讓「工作進來的速度」和「工作被處理的速度」不必完全相同。

**Queue（佇列）**可以想成排隊。

A
B
C
 ↓
Worker

常見基本概念：

FIFO（First In, First Out）

先進去的通常先處理。

但不是所有 Message System 都保證整個系統 Global FIFO；Multiple
Consumers、Partition 等設計可能影響 Ordering。

---

Message 是什麼？

不要把 Message 想得太複雜

Message 就像系統之間傳的一張小紙條。

例如：

「Order 12345 已經建立了」

電腦不能只傳一句模糊的話，所以通常會附上需要的資料：

Event Type
Order ID
User ID

Consumer 看到這張「紙條」後，就知道接下來要做什麼。

Message 是描述「發生了什麼」或「需要做什麼」的一小份資料。

例如：

{
  "event": "ORDER_CREATED",
  "orderId": 12345,
  "userId": 678
}

---

Message Queue 是什麼？

把前面兩個概念合起來

現在已經知道：

Message = 工作資訊 / 通知
Queue   = 排隊等待處理

所以：

Message Queue

就是：

「讓系統之間的工作訊息先排隊，等適合的 Consumer 再拿去處理。」

可以把它想成公司的待辦工作箱：

有人把工作單放進箱子
        ↓
工作人員有空時拿一張
        ↓
處理

Producer 不需要站在 Consumer 旁邊等它做完。

Message Queue 可以理解成：

Application 先把 Message 放進 Queue，其他 Worker / Service
再取出並處理。

Order Service
     ↓
Message Queue
     ↓
Email Service

Order Service 不必等待 Email 真正寄完。

---

Producer 與 Consumer

先用寄件人與收件人理解

最簡單可以記：

Producer = 放工作進 Queue 的人
Consumer = 從 Queue 拿工作來做的人

例如：

Order Service

建立訂單後說：

「有新訂單了」

它是 Producer。

Email Service 收到這個訊息後寄信：

「我要處理這個新訂單通知」

它是 Consumer。

Producer：

產生並送出 Message 的 Service。

Consumer：

從 Queue 取得 Message 並執行工作的 Service。

Producer
   ↓
 Queue
   ↓
Consumer

例如：

Order Service
   ↓
ORDER_CREATED
   ↓
Queue
   ↓
Email Consumer

---

Publish 是什麼？

最簡單的理解

Publish 就是：

Producer 把 Message「送出去」。

像你把一封信投入郵筒：

寫好信
 ↓
投入郵筒
 ↓
郵件系統接手

在這裡：

寫好 Message
 ↓
Publish
 ↓
Message System 接手

Publish 可以理解成：

把 Message 發送到 Message System。

Order Service
 ↓
Publish ORDER_CREATED
 ↓
Queue

---

Message Broker 是什麼？

可以把 Broker 想成「中間的郵局」

Producer 不需要自己找到每一個 Consumer。

Producer
 ↓
Broker
 ↓
Consumer

就像：

寄件人
 ↓
郵局
 ↓
收件人

Broker 幫忙處理「訊息先放哪裡、之後交給誰」這類中間工作。

Message Broker 位於 Producer 與 Consumer
中間，負責接收、保存、Routing、傳遞 Message。

Producer
   ↓
Message Broker
   ↓
Consumer

常見工具：

RabbitMQ
Apache Kafka
Amazon SQS

它們的 Architecture 並不完全相同，所以不要直接理解成完全相同的產品。

---

Message Queue 解決什麼？

常見目的：

Reduce Request Latency
Decouple Services
Buffer Traffic
Retry Failed Work
Scale Background Processing

---

Decoupling 是什麼？

為什麼叫「解耦」？

可以把 Coupling 想成兩個零件綁得有多緊。

如果：

Order Service

一定要直接知道：

Email Service 在哪裡
Analytics Service 在哪裡
Invoice Service 在哪裡

它們就綁得很緊。

Decoupling 的直覺就是：

讓兩邊不要需要知道對方太多細節。

Order Service 只需要說：

「ORDER_CREATED 發生了」

後面誰要處理，可以由其他 Consumer 自己決定。

Coupling 是 Components 彼此依賴的程度。

如果 Order Service 直接呼叫：

Order
 ├── Email
 ├── Analytics
 ├── Invoice
 └── Notification

彼此依賴比較高。

改成：

Order
 ↓
ORDER_CREATED
 ↓
Queue
 ├── Email Consumer
 ├── Analytics Consumer
 └── Invoice Consumer

Order Service 不需要直接控制所有下游 Service。

這叫：

Decoupling（解耦）

---

Buffer Traffic

Buffer 可以想成「蓄水池」

假設突然下大雨：

大量雨水
 ↓
蓄水池
 ↓
慢慢排出去

Queue 就有點像這個蓄水池。

大量 Requests / Jobs
        ↓
      Queue
        ↓
Consumers 慢慢處理

它不是讓工作消失，而是先暫時存著，避免瞬間全部壓到下游 Service。

假設平常：

1,000 Orders/sec

突然 Black Friday：

20,000 Orders/sec

但 Email Service 只能處理：

5,000/sec

Queue 可以暫時吸收工作：

20,000 Messages/sec
        ↓
      Queue
        ↓
Consumers → 5,000/sec

這叫：

Traffic Buffering

---

Backlog 是什麼？

最簡單的理解

Backlog 就是：

「Queue 裡還排著、還沒做完的工作。」

例如：

今天收到 1000 份作業
老師只改完 600 份

那剩下：

400 份

就可以想成 Backlog。

所以 Backlog 一直增加，通常代表：

進來的速度 > 處理的速度

Producer 比 Consumer 快時，尚未處理的 Messages 會累積。

這些等待中的工作叫：

Backlog

Producer Rate > Consumer Rate
        ↓
Backlog increases

如果 Backlog 長時間持續增加，通常表示 Consumer Capacity 不足或 Consumer
發生問題。

---

Throughput vs Latency

用餐廳再區分一次

假設一份餐點平均：

5 分鐘完成

這比較像 Latency。

但整間餐廳一小時可以做：

200 份餐

這比較像 Throughput。

所以：

Latency
→ 單一工作等多久

Throughput
→ 整個系統一段時間能做多少工作

Latency：

一個工作需要多久。

Throughput：

系統一段時間能完成多少工作。

例如：

Latency = 100 ms/message
Throughput = 5,000 messages/sec

兩者不是同一件事。

---

Consumer Scaling

Scaling 在這裡是什麼意思？

如果一個人包貨太慢：

1 Worker → 100 packages/hour

可以增加人手：

4 Workers → 同時處理不同 packages

Consumer Scaling 也是同樣概念：

Consumer 處理不完時，可以增加更多 Consumer 分擔工作。

如果一個 Consumer 不夠：

Queue
 ├── Consumer #1
 ├── Consumer #2
 ├── Consumer #3
 └── Consumer #4

多個 Worker 可以同時處理不同 Message。

這叫：

Parallel Processing

---

Consumer 失敗怎麼辦？

Retry 先記成「再試一次」

Retry 不需要想成複雜演算法。

它就是：

第一次失敗
 ↓
再試一次

例如 Email Provider 暫時斷線，不代表這封 Email
永遠不能寄；等一下重新嘗試可能就成功。

例如 Email Provider 暫時失敗：

SEND_EMAIL
 ↓
Email API ❌

Message System 通常需要：

Retry

Attempt #1 → Failed
Attempt #2 → Failed
Attempt #3 → Success

---

Backoff 是什麼？

為什麼要「越等越久」？

如果某個 Service 已經掛掉，1000 個 Consumer 都一直立刻重試：

失敗 → Retry → 失敗 → Retry → 失敗...

反而會一直攻擊一個已經很忙的 Service。

Backoff 的想法就是：

「它現在可能有問題，我先等一下再試。」

如果還是不行：

「那我再等久一點。」

如果 Service 掛掉，不應該每毫秒瘋狂 Retry。

Backoff：

Retry 前先等待一段時間。

例如：

Retry #1 → wait 1 sec
Retry #2 → wait 2 sec
Retry #3 → wait 4 sec
Retry #4 → wait 8 sec

這種等待時間逐漸增加的方式常稱為：

Exponential Backoff

可以降低 Retry Storm，並給下游 Service 恢復時間。

---

Dead Letter Queue 是什麼？

把 DLQ 想成「問題件專區」

物流公司遇到地址錯誤、一直無法配送的包裹，不會永遠放在正常配送線上循環。

它可能被移到：

問題包裹區

DLQ 就很像這個概念：

正常 Message 一直失敗
        ↓
先移到特殊 Queue
        ↓
之後人工 / 系統檢查

這樣一個壞 Message 不會一直卡住正常流程。

如果 Message Retry 很多次仍失敗，可以送到：

Dead Letter Queue（DLQ）

Main Queue
 ↓
Consumer
 ↓
Failed
 ↓
Retry
 ↓
Still Failed
 ↓
DLQ

Engineer 之後可以：

Inspect
Debug
Fix
Replay

---

ACK 是什麼？

ACK 就像「收到，而且做完了」

假設主管交給你一件工作。

你做完後回：

「完成了。」

這個「完成了」就很像 ACK。

Message System 需要這個確認，才知道：

這個 Message 可以不用再交給別人處理

**ACK（Acknowledgement）**可以理解成：

Consumer 告訴 Message System：「我成功處理完這個 Message 了。」

Queue
 ↓
Consumer
 ↓
Success
 ↓
ACK

---

如果處理成功，但 ACK 前 Crash？

1. Consumer receives Message
2. Send Email succeeds
3. Before ACK → Consumer crashes

Queue 沒收到 ACK，可能再次 Delivery。

結果：

Email sent twice

因此要理解：

Delivery Guarantee

---

At-most-once

名字怎麼記？

把英文拆開：

At most = 最多
Once    = 一次

所以：

At-most-once = 最多一次

寧可有機會沒處理到，也避免系統主動重複處理很多次。

At-most-once：

最多一次

可能是：

0 次
或
1 次

降低 Duplicate，但可能有 Message Loss 的 Trade-off。

---

At-least-once

名字怎麼記？

At least = 至少
Once     = 一次

所以：

At-least-once = 至少一次

為了避免 Message 遺失，系統可能重新送，因此 Consumer 必須接受：

同一個 Message 可能再來一次

At-least-once：

至少一次

系統努力避免漏掉 Message，但可能 Delivery：

1 次
2 次
3 次

所以 Consumer 必須考慮 Duplicate。

---

Exactly-once

名字看起來簡單，實作卻很難

Exactly once = 剛好一次

理想上當然希望：

不漏掉
+
不重複

但 Distributed System 很難確認：

「對方到底沒做？」
還是
「其實做完了，只是 ACK 沒傳回來？」

這就是 Exactly-once 困難的直覺來源。

Exactly-once 的目標是讓 Effect 只發生一次。

但 Distributed System 可能遇到：

Network Failure
Consumer Crash
Database Commit
ACK Failure
Retry

因此真正 End-to-End Exactly-once 並不簡單。

實務上很重要的一個問題反而是：

如果 Message 重複，我的 Consumer 能不能安全地再次處理？

這就引出：

Idempotency

---

Idempotency 是什麼？

用「電梯按鈕」理解 Idempotency

你要去 5 樓：

按一次 5 樓

和：

連按 10 次 5 樓

正常情況下，電梯不會因此去 5 樓 10 次。

最後目的仍然是：

5 樓

這就是理解 Idempotency 很好用的直覺：

同一件要求重複出現，不應該造成不合理的重複結果。

Idempotency 中文常翻成「冪等性」。

直接記概念：

同一個 Operation
執行一次或重複執行，最終不應產生不應該的重複副作用。

例如：

Set status = ACTIVE

做一次：

ACTIVE

做十次：

ACTIVE

結果仍相同。

---

Payment 為什麼需要 Idempotency？

假設重複收到：

CHARGE_PAYMENT
order_id = 123
amount = $100

如果兩次都 Charge：

$100 + $100 = $200 ❌

可以使用：

Idempotency Key

例如：

payment:order:123

處理前先確認：

這個 Payment 是否已成功？

已完成就不要再次 Charge。

因此：

At-least-once Delivery 常需要搭配 Idempotent Consumer。

---

Event 是什麼？

Event 就像「發生事情的通知」

例如學校系統說：

STUDENT_REGISTERED

它不是命令某一個人一定要做什麼。

它只是宣布：

「有一位 Student 已經註冊完成。」

收到通知的人可以各自決定：

Email Service → 寄信
Analytics → 記錄
Profile Service → 建資料

Event 可以理解成：

描述「某件事情已經發生」的 Message。

例如：

ORDER_CREATED
PAYMENT_COMPLETED
USER_REGISTERED

Event 通常描述 Past Fact。

---

Command vs Event

一句話分辨

可以問：

這句話是在「叫別人做事」
還是在「描述已經發生的事」？

例如：

SEND_EMAIL

是叫人做事，所以比較像 Command。

ORDER_CREATED

是在說事情已發生，所以比較像 Event。

Command：

SEND_EMAIL

比較像：

請做這件事。

Event：

ORDER_CREATED

比較像：

這件事已經發生。

一個 Event 可以有多個 Consumer：

ORDER_CREATED
       ↓
 ┌─────┼────────┐
 ↓     ↓        ↓
Email Analytics Invoice

---

RabbitMQ 是什麼？

初學者先把它放在哪個位置？

今天不需要記 RabbitMQ 的內部設計。

先記：

Producer
 ↓
RabbitMQ
 ↓
Consumer

也就是 RabbitMQ 可以扮演中間幫忙傳遞 Message 的 Broker。

等真正使用 RabbitMQ 時，再學 Exchange、Binding、Routing Key 就好。

RabbitMQ 是常見的 Message Broker，常用於：

Task Queue
Message Routing
Background Job
Service Messaging

今天先理解：

Producer → RabbitMQ → Consumer

不需要先深入 Exchange、Binding 等細節。

---

Kafka 是什麼？

初學者先不要把 Kafka 想得太複雜

可以先想像一條持續記錄事件的流水帳：

#1 User Registered
#2 Order Created
#3 Payment Completed
#4 Order Shipped
...

Event 持續被寫進去，Consumer 可以按照自己的進度讀取。

這只是建立直覺；Kafka 真正的設計還有 Partition、Offset、Consumer Group
等概念，之後再拆開學。

Kafka 常被描述為：

Distributed Event Streaming Platform

先理解 Event Streaming：

大量 Event 持續產生，系統持續記錄，Consumer 再讀取與處理。

例如：

User Click
Order Created
Payment Completed
Page Viewed

Kafka 常見於：

Event Streaming
Analytics Pipeline
Log Processing
Data Pipeline
Event-driven Architecture

之後再深入：

Topic
Partition
Offset
Consumer Group

---

Topic 是什麼？

Topic 就像「分類資料夾」

例如 Email Inbox 可能有不同分類。

Kafka / Messaging 裡也可以把不同類型 Event 分開：

orders
payments
users

Consumer 如果只在意 Order，就主要讀：

orders

所以 Topic 先記成：

Message / Event 的分類名稱。

Topic 可以理解成：

某一類 Message / Event 的分類。

例如：

orders
payments
user-events

ORDER_CREATED 可以放在：

orders topic

---

Event-driven Architecture 是什麼？

最簡單的想法

傳統方式可能是：

A 直接叫 B
A 再直接叫 C
A 再直接叫 D

Event-driven 比較像：

A 宣布：「某件事發生了」
        ↓
有興趣的 B、C、D 自己反應

重點是：

系統的後續行為由 Event 驅動。

Event-driven Architecture：

不同 Component 透過 Event 通知「發生了什麼」，其他 Component 再根據
Event 做反應。

Order Service
 ↓
ORDER_CREATED
 ↓
Event System
 ├── Email
 ├── Analytics
 ├── Inventory
 └── Notification

---

Consumer Lag 是什麼？

Lag 就是「落後多少」

可以想像老師播放教學影片已經到：

第 100 分鐘

但你只看到：

第 70 分鐘

那你落後：

30 分鐘

Consumer Lag 也是類似概念：

Producer 已經產生很多 Event
Consumer 還沒追上

Consumer Lag 可以理解成：

Consumer 還落後多少尚未處理的 Event。

例如 Producer 已產生：

1,000,000 Events

Consumer 只處理到：

900,000

還落後：

100,000

Consumer Lag 很大可能代表：

Consumer Too Slow
Traffic Burst
Consumer Failure
Insufficient Capacity

---

Message Ordering

為什麼順序重要？

生活中：

先下單
再取消

和：

先取消
再下單

結果可能完全不同。

Message 也是一樣。

所以 Ordering 就是在問：

這些 Message 被 Consumer 處理時，是否需要維持特定先後順序？

假設：

Event 1 → ORDER_CREATED
Event 2 → ORDER_CANCELLED

如果 Consumer 反過來處理，State 可能出問題。

因此某些情境需要：

Ordering Guarantee

但 Global Ordering 可能限制 Parallelism 和 Scalability。

所以常見 Trade-off：

Strong Ordering
vs
High Parallelism

有些系統只需要：

同一個 Order 的 Events 保持順序

而不是所有 Orders 都共用一條全球順序。

---

Durability 是什麼？

用「寫在紙上」vs「只記在腦中」理解

如果重要事情只記在腦中：

忘記 → 資料沒了

如果寫下來並保存：

即使人離開
資料仍然存在

Message Durability 也是類似概念：

重要 Message 被系統接受後，希望即使 Server Crash，也不要輕易消失。

Durability 可以理解成：

Message 被成功接受後，即使 Server Failure，也希望資料不要輕易消失。

例如 Broker 收到：

ORDER_CREATED

下一秒 Crash。

Message 還在嗎？

Production Message System 可能透過：

Persistent Storage
Replication
Cluster

提高 Durability。

---

Message Queue 的 Trade-off

Trade-off 再提醒一次

Trade-off 不是「缺點很多所以不要用」。

它的意思是：

得到某些好處的同時，也必須接受新的成本。

Message Queue 讓系統更容易 Async、Buffer、Retry，但 Engineer
也要負責處理 Duplicate、Ordering、Monitoring 等新問題。

好處：

Lower Request Latency
Decoupling
Traffic Buffering
Retry
Independent Scaling

代價：

Infrastructure Complexity
Duplicate Messages
Ordering Problems
Backlog
Monitoring
Debugging
Eventual Processing

所以不要看到 Microservices 就自動加入 Kafka。

仍然要問：

我們到底在解決什麼 Problem？

---

台積 IT 面試情境：Welcome Email 很慢

假設：

User 註冊後要寄 Welcome Email，但 Email API 常需要 3
秒，而且偶爾失敗，怎麼改善？

原本：

Register
 ↓
Email API
 ↓
Wait
 ↓
Response

可以改成：

Register User
 ↓
Publish USER_REGISTERED
 ↓
Response

Queue
 ↓
Email Consumer
 ↓
Send Email

失敗：

Retry
 ↓
Backoff
 ↓
Still Failed
 ↓
DLQ

並考慮 Duplicate Delivery 與 Idempotency。

---

台積面試延伸：Black Friday

Normal Orders = 1,000/sec
Black Friday  = 20,000/sec
Analytics Capacity = 5,000/sec

Queue 可以暫時 Buffer：

20,000 Events/sec
        ↓
      Queue
        ↓
Consumers → 5,000/sec

同時 Monitoring：

Backlog
Consumer Lag
Processing Rate
Failure Rate
DLQ Size

---

System Design Architecture 再進化

User
 ↓
CDN
 ↓
Load Balancer
 ↓
Backend
 ├──→ Redis
 ├──→ Database
 └──→ Publish Event
          ↓
     Message Queue
      /    |     \
     ↓     ↓      ↓
  Email Analytics Notification

我們現在開始處理：

Async Processing
Service Decoupling
Traffic Burst
Failure Retry

---

台積 IT 面試準備 Checkpoint

1. Synchronous 是什麼？
2. Asynchronous 是什麼？
3. Critical Path 是什麼？
4. Queue / FIFO 是什麼？
5. Message Queue 是什麼？
6. Producer / Consumer 是什麼？
7. Message Broker 是什麼？
8. Publish 是什麼？
9. Decoupling 是什麼？
10. Traffic Buffering 是什麼？
11. Backlog 是什麼？
12. Throughput vs Latency？
13. Consumer Scaling？
14. Retry 是什麼？
15. Exponential Backoff 是什麼？
16. Dead Letter Queue 是什麼？
17. ACK 是什麼？
18. At-most-once？
19. At-least-once？
20. Exactly-once 為什麼不簡單？
21. Idempotency 是什麼？
22. Payment 為什麼需要 Idempotency？
23. Event vs Command？
24. RabbitMQ 是什麼？
25. Kafka 是什麼？
26. Topic 是什麼？
27. Event-driven Architecture 是什麼？
28. Consumer Lag 是什麼？
29. Message Ordering 為什麼重要？
30. Durability 是什麼？
31. Welcome Email 很慢怎麼設計？
32. Black Friday Traffic Burst 怎麼保護 Downstream？

---

今天學到了什麼？

Message Queue 核心：

Producer
   ↓
Message Queue
   ↓
Consumer

可以幫助：

Reduce Request Latency
Decouple Services
Buffer Traffic
Retry Failed Work
Scale Consumers

但也帶來：

Duplicate Messages
Ordering Problems
Backlog
Retry Complexity
DLQ
Monitoring
Infrastructure Failure

最重要的一句：

Message Queue 讓 Producer 和 Consumer
不必在同一時間、用同樣速度完成工作，藉此換取更好的
Decoupling、Scalability 與 Failure Handling。

---

下一篇

如果某個 Client 每秒送：

100,000 Requests

即使後面有 Load Balancer、Cache、Replica、Queue，系統仍可能被壓垮。

下一篇：

Day 12｜Rate Limiter：如何防止 API 被大量 Request 打爆？

會先從零解釋：

Rate
Request Rate
Threshold
HTTP 429

再進入：

Rate Limiter
Fixed Window
Sliding Window
Token Bucket
Leaky Bucket
Redis Counter
Distributed Rate Limiting

以及：

Rate Limiter 放哪裡？
多台 Backend 如何共用 Counter？
Redis 掛掉怎麼辦？
Fail Open vs Fail Closed？